This doesn't particularly have a "page" nature; it'd work just
as well as one thing on a larger page, if it came to that.

I was rereading some of the code that uses these classes, and found
I had to reread their implementation to refresh myself on what they
each did.

In particular this provides a back button so that the user can
go try something else instead of waiting for the app to finish
getting data from the server.  (On Android the user could already
do so, using the system back gesture or button, but there's no
such thing on iOS.)

Now PerAccountStoreWidget has just two constructor call sites
in the app.  There's one for the flight shuttle in LightboxHero,
a rare example of a widget not belonging to any page; and then
the one in AccountPageRouteMixin covers every page in the app
that needs a per-account store.

This has the same effect, but gives us a more general form
of API to work with for more complex effects.

Effectively `onGenerateRoute` is a fallback for when a route name
isn't resolved by `home` or `routes`; and this version has the
same effect as the `home` (and omitted `routes`) we'd been providing.

I find the relevant area of the docs somewhat hard to follow, so to
see this in the implementation: the main effects of both `home` and
`onGenerateRoute` are implemented in [WidgetsApp._onGenerateRoute],
and the one other effect is in [WidgetsApp._usesNavigator].
The [MaterialWidgetRoute] part corresponds to `pageRouteBuilder`,
which is specified by the [MaterialApp] implementation.

The base class offers six methods, so we may as well provide
access to all six of them in the same way.

This mimics what the default implementation of onGenerateInitialRoutes
was doing, given that we never specify initialRoute and given our
implementation of onGenerateRoute.

This will let us use the global store in computing our arguments
for MaterialApp.

These tests had been relying on the fact that there wouldn't be any
PerAccountStoreWidget that reached the point of attempting to load
data for these accounts.  But that was true only because, after
opening a notification, the test code waited only for microtasks
(with `await null`), and not for a new frame (like `tester.pump()`).

That makes them brittle, as they'd break on an otherwise innocent
change to pump another frame.  Fortunately it's easy to fix.

Fixes: zulip#516